perm filename CLNTLN.MSG[COM,LSP]1 blob
sn#845011 filedate 1987-08-18 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂10-Aug-87 2322 BAGGINS@IBM.COM CLtl Natural Languages Subcommittee
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 10 Aug 87 23:22:29 PDT
Date: Mon, 10 Aug 87 23:22:01 PDT
From: "Thomas Linden (Thom)" <baggins@ibm.com>
To: Common Lisp Natural Language Support mailing
<cl-natural-languages@sail.stanford.edu>
cc: "Richard P. Gabriel" <rpg@sail.stanford.edu>
Message-ID: <870810.232201.baggins@IBM.com>
Subject: CLtl Natural Languages Subcommittee
Through the good graces of Dick Gabriel, we now have a mailing
list set up at sail (see To: above) for the National Languages
Subcommittee. From the last ANSI meeting, I have down as
committee members:
Thom Linden - baggins@ibm.com
Larry Masinter - Masinter.pa@xerox.com
Carl Hoffman - cwh@fuji.ila.dialnet.symbolics.com
Bob Kerns - rwk@scrc.symbolics.com
Duncan Missimer - (don't know netid)
Dave Mathews - dcm%hpfclp@hplabs.hp.com
Mike Beckerle - mike%acorn@oak.lcs.mit.edu
Send updates to the mailing list (eg. you're on the list
and should'nt be) to Dick. If anyone knows Duncan's netid,
please pass it along so he can be added to the distribution.
Just as a check, please acknowledge this message. Thus, I
will have some confidence we are actually connected.
I suspect with vacations underway, our conversation on NLS
won't begin until September (eg. I'll be out for the remainder of Aug).
But, starting in Sept, I would like to see us in an active mode.
The first order of business should be an acknowledgement note
sent to JEIDA. After that we need to agree on the scope of
our effort and the protocols we wish to follow .. eg.
we could follow the pattern set by the Cleanup Subcommittee
status reports and documentation or by the CommonLoops group.
Perhaps the first thing we should decide is our name and what
a proposal arising from our efforts would be called. I start
this off by suggesting:
National Languages Support (ie. NLS subcommittee) and
"Extensions to Common Lisp Character Handling"
Natural Languages is a nicer term as it doesn't seem to have
a connection to political boundaries. Unfortunately, it seems
heavily used in the linguistics field. Some folks use
DBCS for Double Byte Character Support but that seems clearly
tied to an implementation decision.
... well, these comments will hopefully test the networking.
I'll see you in a few weeks.
Regards,
Thom
∂11-Aug-87 1749 masinter.pa@Xerox.COM Re: CLtl Natural Languages Subcommittee
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Aug 87 17:49:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 87 17:22:33 PDT
Date: 11 Aug 87 15:16 PDT
From: masinter.pa@Xerox.COM
Subject: Re: CLtl Natural Languages Subcommittee
In-reply-to: "Thomas Linden (Thom)" <baggins@ibm.com>'s message of Mon,
10 Aug 87 23:22:01 PDT
To: baggins@ibm.com
cc: cl-natural-languages@sail.stanford.edu, rpg@sail.stanford.edu
Message-ID: <870811-172233-1210@Xerox>
I had hoped that this committee could deal also with the issue of font
and font attributes as well as character codes. I'd been filing things
under the heading of "Common Lisp Characters", since that seemed to have
the broader charter.
My comments at the last X3J13 committee is that, while there may still
be important reasons for retaining a user-visible distinction between
thin-simple-string and simple-string, there seemed to be little or no
reason to have any visible distinction between thin-string and string,
since the general string case, with displacement and the like, can be
implemented as efficiently.
This modification of the JEIDA proposal removes most of its complexity
while retaining most of its benefits.
∂11-Aug-87 1749 masinter.pa@Xerox.COM Re: CLtl Natural Languages Subcommittee
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Aug 87 17:49:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 87 17:39:29 PDT
Date: 11 Aug 87 15:16 PDT
From: masinter.pa@Xerox.COM
Subject: Re: CLtl Natural Languages Subcommittee
In-reply-to: "Thomas Linden (Thom)" <baggins@ibm.com>'s message of Mon,
10 Aug 87 23:22:01 PDT
To: baggins@ibm.com
cc: cl-natural-languages@sail.stanford.edu, rpg@sail.stanford.edu
Message-ID: <870811-173929-1259@Xerox>
I had hoped that this committee could deal also with the issue of font
and font attributes as well as character codes. I'd been filing things
under the heading of "Common Lisp Characters", since that seemed to have
the broader charter.
My comments at the last X3J13 committee is that, while there may still
be important reasons for retaining a user-visible distinction between
thin-simple-string and simple-string, there seemed to be little or no
reason to have any visible distinction between thin-string and string,
since the general string case, with displacement and the like, can be
implemented as efficiently.
This modification of the JEIDA proposal removes most of its complexity
while retaining most of its benefits.
∂14-Aug-87 1714 dcm%hpfclp@hplabs.HP.COM Re: CLtl Natural Languages Subcommittee
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Aug 87 17:13:41 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Fri, 14 Aug 87 12:02:54 pdt
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Fri, 14 Aug 87 13:00:27 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Fri, 14 Aug 87 13:01:51 mdt
Return-Path: <dcm@hpfcdcm>
Message-Id: <8708141901.AA04264@hpfcdcm.HP.COM>
To: cl-natural-languages@sail.stanford.edu
Cc: rpg@sail.stanford.edu
Subject: Re: CLtl Natural Languages Subcommittee
X-Mailer: mh6.5
In-Reply-To: Your message of Mon, 10 Aug 87 23:22:01 -0700.
<870810.232201.baggins@IBM.com>
Date: Fri, 14 Aug 87 13:01:48 MST
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
Duncan Missimer's mail address is
missimer%hpcldbm@hplabs.hp.com
Please add him to the mailing list.
At HP we use the acronym NLS for Native Language Support - the ability
for a user to communicate with his/her machine in his/her native
language. This seemed more appropriate because there is not always a
singular mapping of languages to nationalities.
Dave Matthews
∂18-Aug-87 0557 RWK@YUKON.SCRC.Symbolics.COM Re: CLtl Natural Languages Subcommittee
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Aug 87 05:57:32 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 249013; Fri 14-Aug-87 03:44:20 EDT
Date: Fri, 14 Aug 87 03:44 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: CLtl Natural Languages Subcommittee
To: masinter.pa@Xerox.COM
cc: baggins@ibm.com, cl-natural-languages@sail.stanford.edu
In-Reply-To: <870811-172233-1210@Xerox>
Message-ID: <870814034421.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 11 Aug 87 15:16 PDT
From: masinter.pa@Xerox.COM
I had hoped that this committee could deal also with the issue of font
and font attributes as well as character codes.
Yup. I plan to propose we delete 'em. Details later.
I'd been filing things
under the heading of "Common Lisp Characters", since that seemed to have
the broader charter.
My comments at the last X3J13 committee is that, while there may still
be important reasons for retaining a user-visible distinction between
thin-simple-string and simple-string, there seemed to be little or no
reason to have any visible distinction between thin-string and string,
since the general string case, with displacement and the like, can be
implemented as efficiently.
This is a lot easier for you or I to say, on our special Lisp engines,
than it is for those on "stock" hardware. But even for us, it's not
really true. Creating a large string of the wrong size, and then copying
the whole thing when a "fat" character comes along, could prove quite
expensive. And on our system, once that was done, every reference to that
string would be slowed down by an extra memory reference. Everybody else
would have to pay this price ALL the time, except when they can use simple
strings.
Don't forget that (AND STRING (NOT SIMPLE-STRING)) does NOT mean that
the string is displaced. It may be a non-displaced non-adjustable
string with a fill-pointer. What you're proposing really means changing
this so that, on stock architectures, (AND STRING (NOT SIMPLE-STRING))
implies that it's displaced, so that the data can be "fattened".
This modification of the JEIDA proposal removes most of its complexity
while retaining most of its benefits.
I don't think it removes the complexity; it introduces complexities of
its own. Of course, it also has benefits of its own. But I don't want
to waste time designing it unless we have some assurance that it really
isn't going to be a burden for the stock architectures, and the understanding
I have from the conversations I've had is that it would be a burden for them.
I'm about to leave until Labor Day. I'll have lots more stuff to send when
I get back.